Typical examples for network applications using a presence service are chat and messaging applications monitoring the presence status of their users. Other more advanced examples include systems integrating reliability mechanisms. For instance fault tolerant systems may include two servers, one working to serve users' requests, while the other server is idle, in order to substitute the first server upon failing. A presence service in this case would provide a notification in case the first server stops working, i.e. when it is not present anymore, so that the second idle server can immediately substitute the first server. Other examples include mobile IP and IPSec presence services (available under http://www.pasieronen.com/publications/NRCTR2008002.pdf).
In the non-patent literature of XMPP according to RFC 3921 (which is available under http://www.rfc-editor.org/rfc/pdfrfc/rfc6121.txt.pdf) an example of a protocol is shown supporting a presence service. Conventional presence services, for example in a computer network are provided such that an entity which is monitored by the presence service sends periodic messages to the presence service. The periodic messages are usually called keepalive messages or heartbeat messages. The presence service monitors that a keepalive message is received in each predetermined time period. The absence of a keepalive message then indicates that the monitored entity is not present anymore, for example was shut down or is offline from the network.
The keepalive message sending period and the number of missing keepalive messages after which the monitored entity is considered as “absent” are configuration parameters of the presence service which are, for example, shown in further non-patent literature (specifically that available under http://www.cs.bham.ac.uk/˜pxt/PAPERS/stillAliveFinal.pdf).
A conventional implementation of a presence service is to use a presence server. The presence server accepts monitoring requests for registering one or more entities to the presence service to activate the corresponding presence monitoring of the registered entities. At the same time the registered entities start sending periodic keepalive messages to the presence service. When a registered entity goes offline, i.e., when the keepalive messages stop reaching the presence service then the presence service changes the status of the registered entity to “absent” and usually the change of the status of a registered entity is notified to an application for performing an action to this information.
The keepalive or heartbeat messages are usually very small messages in terms of bytes which are sent for the sole purpose of “refreshing” the presence status in the presence service. However keepalive messages need to travel from each monitored entity to the presence service and this increases the number of small packets the network has to deliver.
On the other hand the presence service has to collect all these keepalive messages and update the state of the corresponding monitored entity according to the received keepalive packets. Usually also timers are involved that need to be reset at the reception of a corresponding keepalive packet. The presence service hence, needs to scale with the number of keepalive messages that are sent. This is related to the total number of users of the presence service and the keepalive periods.
Further, different applications are required to implement their own presence services because operations of these applications require such a service. However, this causes to deploy plurality of presence services or in other words high costs for an operator of the network.